In traditional networks, the functionality of a network node is coupled with a physical device and, hence, the establishment of a network service involves setting up physical devices, their connection and configuration. If demands change for an existing service or a new service is demanded, the network operator needs to add or remove devices from the network to increase or decrease capacity or functionality.
A particular service may comprise a plurality of functions to be executed. A function is responsible for a specific treatment of packets received by the function. The function can be embedded in a physical network element or be a software instance (e.g. a virtual network function), running on a (virtualized) physical infrastructure.
Network Function Virtualization (NFV) is a method to decouple network functions, e.g. router, firewall, application layer gateway, virus scanner from the physical device using virtualization technologies, such as VMware. Virtualization enables physical devices to be regarded as resources on which network functions can be loaded dynamically. For example, when a network service is required to filter traffic at a certain location in a network, NFV allows allocation of a firewall network function to a physical device (e.g. a cloud datacentre). Every Virtual Network Function (VNF) is hosted on one or more Virtual Machines (VMs). A VM emulates a physical machine, making it possible to host multiple VMs on a single physical machine. Every VM makes use of a share of the physical machine's resources. These physical resources include CPU, memory, bandwidth, and disk space.
A service can be described as a Service Function Chain (SFC). An SFC defines a set of one or more network functions for a service and ordering constraints for the functions through which data packets are exposed. To instantiate a service, the SFC is executed by a NFV Management and Orchestration system, e.g. like defined in ETSI NFV. It includes a NFV Orchestrator that manages the service lifecycle and coordinates the management of the relevant resources to ensure an optimized allocation of the necessary resources and connectivity. Shatzkamer et al (US 2014/0317261 A1) describe one way of implementing such an NFV Orchestrator function.
Service demand may be volatile and difficult to predict. As a consequence, a service may not be available because too few resources are available or resources may be underutilized because a service is less popular than predicted. The NFV Management and Orchestration functionality is able to coordinate the management of the resources relevant for execution of an incoming SFC. However, if resources are not already readily available (pre-allocated) for the network service represented by the SFC when the SFC is entering the NFV Orchestrator, it will take a long time (minutes to hours) before the needed resources are freed and allocated and the SFC can actually be executed and the service instantiated. This delay adds to the delay already introduced by having the SFC travel through the complete network (from user equipment all the way to the operators backend systems) before it enters the NFV Orchestrator. Network operators therefore excessively pre-allocate resources so that SFCs can be executed faster and with a larger chance of success. This is a waste of resources.
In addition, it is possible that an incoming SFC in the NFV Orchestrator turns out to be already instantiated, or close to be instantiated (e.g. the VNFs are already there on the right VMs, but they need to be configured slightly differently). It takes a long time before NFV Management and Orchestration functionality becomes aware of this fact and then decides to do almost nothing. Or, on the contrary, the NFV Management and Orchestration functionality decides to pre-configure and/or pre-load various VNFs already, before the SFCs are received, as a way of pre-provisioning the service because it expects many SFC s to arrive in the future. This is again a waste of resources.